施工中。。。

前言

本文默认你已经看过之前的计算机网络科普,或者说你已经掌握这些知识点。

另外,之前还出了两篇介绍处理网络故障的工具,强烈建议去看一看。

本文将介绍一些常见的网络故障与排查思路,主要适用于家庭与公司内部网络;

运营商一侧的维护不介绍(只要会判断是不是它们的问题即可,是运营商问题,直接摇人便是。)

本文更多是让读者进行学习,内化为自己的知识,并不是一本可以在现场直接照着进行操作的攻略书。

同时网络故障千奇百怪,想写一本通用的排查手册几乎不可能。

我希望读者能在空闲时间读完全文,思考一下,进行内化。

稍微啰嗦一下:

一般来说,后期维护并不需要涉及太多网络配置相关的东西(指路由配置、策略配置、权限配置等),大部分的故障都是物理层链路层处的故障,小部分为人为因素故障。

因此,遇到网络故障了,第一时间是腿动起来,拿着工具去测。(当然我们还是得先进行故障现象验证、一些基础的检查与测试,这部分之后详细说)

一定不要有在电脑上各种测试、调试就能判断故障问题甚至直接解决故障的定性思维。

举个实际我碰到过的例子,在某项目地,有一台设备不定时的丢包。

某公司的网络工程师在那用笔记本使用命令进行各种调试,甚至进到汇聚交换机后台去检查,折腾了很久都没解决(中途我跑去干饭了)。

后来收到该兄弟的微信,说他有事先去别的地方忙,告诉了我刚刚那台设备是连接在交换机上第几口(后台看arp表看的),让我去机房换个交换机接口试试。

我换完回去测试,依旧存在丢包的现象,于是我就去检查线路了,很快就在线槽下的延长转接处发现网线破皮了。

为啥我不一开始就去干?

因为一开始人家(甲方/业主)就不是叫我去处理这个事情,我没有理由去揽分给其他公司的活,给自己没事找事。

二是因为我个人不喜欢在别人埋头处理事情时去插手插嘴,一方面这会打断对方的思路,另一方面是很可能我需要花费不少时间去解释要做什么、为什么做,以及还要看对方听不听你的,愿不愿意让你现在操作。不如等他都处理完了,我再以我自己的思路去处理一遍,还不用动嘴解释。

以上啰嗦了,现在回到主题,我们先简要介绍一下本文的大纲。

第一部分会介绍更加底层的信息/数据是怎么传输的,这有利于去解释一些“玄学”的故障问题。

第二部分会介绍常见的网络故障类型与大致现象

第三部分则介绍从接到报障电话开始,如何快速的缩小故障排查范围,尽可能快的判断处故障原理/解决网络故障。

碍于篇幅,本文默认你已经掌握了基础计算机网络知识与各类工具,如果你有不太清楚的,可以翻看上两篇文章。

数据传输的本质

码元、编码、解码与网线传输的原理

计算机内部的信息都是0与1组成的。

进行信息传输,就需要想办法怎么表示0与1。

码元就是用来区分0与1的。

而编码,就是将数据转换为码元的过程,解码就是反过来的过程。

码元是基于高电平与低电平来表示的。

网线传输的本质是传播电信号——网线为铜线也就是导线,线芯之间的电平变化就是码元信息的表示。

这也是干网络布线的被称为“弱电”的原因

在大概了解这个原理后,我们来分析一下。

为什么网线要做成“双绞线”?

因为双绞线抗干扰,我想很多人都知道。那为啥抗干扰呢?又为啥有干扰呢?这可能有些人就答不出来了

  • 电能生磁、磁也能生电,如果网线处于一个有磁场变化的环境,导致线路内部的电平发生了变化,这就会导致这是传输的信息错误。
  • 双绞线通过紧密贴合与双绞,让干扰发生后,虽然电平是变化了,但是两芯线保持同等变化,最终电平差值保持不变,不影响信息判断。
  • 也是因此,我们才有了水晶头线序的规范。来,我们思考一下,最基础的通信是不是1236,12是不是同一对双绞线,36是不是同一对双绞线。

RS-232、RS-485通信

串口信号传输,本质也跟网线传输一样,就不赘述了。

这边推荐个视频看看了解一下,反过来,可以通过这个视频,去理解一下网线传输是怎么样的。

5分钟看懂!串口RS232 RS485最本质的区别

常见故障类型与现象

碍于篇幅,只简单提及,毕竟具体介绍,每一种都能单独写一篇文章出来。

DHCP获取失败

当设备网络设置为自动获取时,它会周期性的去寻找DHCP服务请求IP地址等信息。

如果持续一段时间找不到,该设备会使用169.254.0.0网段的IP地址作为临时IP地址(可与其他相同境遇的设备进行通信)

IP冲突

当设备IP冲突时,如果设备自身未检测到冲突,它会保持使用该IP地址,那么就可能出现网络时断时续的情况。

这是因为交换机分不清回来的数据交给该设备还是与该设备IP相同的另一台设备。

如果设备自身检测到冲突,那么它不会使用该IP地址,为此,它也会像DHCP获取失败一样使用169.254.0.0网段的IP地址作为临时IP地址。

也许你体验过这种情景,给设备手动设置的静态ip,但是检查网络信息的时候,发现电脑死活就是首选使用一个169.254.0.0网段的IP地址。(而你又想着你明明没有使用自动获取,为此犯迷糊了)

DNS故障

DNS故障表现为部分网站/应用无法上网,因为DNS的作用是将域名翻译为ip地址,网络通信实际是以IP为标准的。

但DNS故障,无法将域名准确的“翻译”为IP地址,就会导致访问该域名失败。

二层环路

二层环路会导致网络中广播包大量存在,无法停止,最终占用大量网络资源(之前出过文章介绍,可以去看看)

在Windows里我们可以使用netstat -e命令,查看广播包的收发情况(也叫非单播包)

三层环路

三层的环路主要是单播包来回传,但由于三层包中有TTL限制,也就是数据包传播次数有上限,因此三层环路一般不会很快发展到引起网络故障,但三层环路依旧值得关注。

三层环路的成因是路由设置有误,一般搭建好、未在进行配置修改的网络中,这个故障可能性几乎为0。

链路与硬件故障

这个就很好理解了,设备或者设备接口、网线、光纤、模块、分光器、光纤收发器等坏了导致网络故障

设备过热与过载

交换机与路由器,本质也是一台计算机,计算机会有的故障,它们也会有。

设备过热导致降频甚至死机,影响数据传输,就导致网络故障。

或者设备负荷过大,处理不过来,就导致网络卡顿甚至死机。

网络代理

代理,也就是网络中转站。

一般来说,有一些网络资源,我们设备本身无法访问到或者是访问速度慢,就开启代理,让代理服务器去处理。(加速器与科学上网的本质)

如果因为一些其他情况,代理服务器无法访问目标网络资源,而我们设备开着代理,就会导致网络故障。

带宽被大量占用

带宽被占满,会导致网络“延迟、卡顿、丢包”。常见的就是同局域网下,有人占满网速在下载东西,会导致其他人“卡了”。

网络攻击

这边不做专门介绍了,网上有很多文章介绍网络攻击。

这边提出来只是让读者不要忽视了这个可能性,虽然平时很少遇到,但确实有这个可能性。

如果是电脑中病毒,然后自主的对外传大量传数据这种情况其实是算上一个故障类型。

故障处理思路

请不要跳过上文,直接观看本段!本段内容都是默认你已经看过上文了。

发现故障阶段

抵达现场

接到报障时,我们应该着重询问了解故障范围、故障现象与出现时间/周期、尤其要询问前一天是否正常,或者说最近一次使用时间。

到达现场之后,一起要记得自己去测试一次,切记不可听信用户自己的描述,必须自己操作一遍观察故障现象。

在验证故障的过程中,嘴巴也别闲着,前面第一段那些问题没了解清楚的,在这时继续询问用户。

同时询问用户最近是否有什么变动,类似系统升级、安装了软件、周围或者办公室内有施工、设备是否更换等等。

验证完故障时,一定要问一句用户附近有交换机/路由器吗。

确定故障范围

这是很重要的一步,故障范围可以快速的帮助确定故障点。

但并不绝对,一定要记得,故障原因没有绝对,都是可能性,我们的工作是考虑可能性,再逐一排除可能性。

“从怀疑到验证”重复这个过程,并不是”怀疑=确信“。

  • 如果故障范围不小,比如一间办公室。那么显然,故障大概率不是出在终端设备这边(一般指电脑),排查重点在这些设备的上行链路(上层交换机/路由器)
  • 故障范围限定于一台终端设备,那么我们的排查重点就是在设备这边,以及设备到达机房的这段链路。
  • 故障范围仅限于终端设备上的部分情景(譬如只有部分网站打不开等),那么我们可以暂时排除线路故障。排查重点在于DNS、防火墙“上层应用”,以及对端设备(比如网站的服务器一侧,包括服务器本身与服务器到网关的链路)

排查阶段

进行基础测试

检查终端的网络状态

以window11为例(我知道很多人都用不习惯,但是作为运维人员,你不能说不好用就拒绝学习,用户电脑系统就用win11,你现场摸瞎搞被人当成不专业吗)

打开控制面板的更改网络设配器界面(三种方法任选一种):

我知道ipconfig /all 一样的效果,但是可视化程度,易读性上还是进设配器界面好,同时还方便后面可能进行的手动设置。

  1. Windows11直接在系统搜索处输入”网络连接“,按回车进入传统的网络设配器界面。(搜索不需要鼠标去点,键盘按一下Windows键,在开始菜单界面输入文字就自动进入搜索状态)

  2. win+R或者其他方式打开运行窗口,输入ncpa.cpl

  3. 打开控制面板,点击网络和共享中心,点击更改设配器设置。(如何打开控制面板不在此赘述)

选中当前使用的设配器(网卡),双击或者右键点击状态,打开状态界面。

在状态界面点击详细信息,打开详细信息界面。

解读一下网络信息

第一眼关注状态窗口下方的”活动“,观察已发送与已接收流量是否正常。

  • 如果是字节数只有发送,而接收为0,初步可以怀疑IP冲突或者DHCP获取IP失败。(可以通过禁用再启用,刷新字节数)
  • 如果接收的字节数量增加速度很快,并且确认当前设备未在下载东西,那么需要怀疑一下环路或网络攻击等会占用大量网络资源的故障因素。

第二眼关注详细信息里的ip、掩码、网关,记录下来。

  • 假设ip地址为169.254.X.X;则说明该设备目前没有正常的ip地址可用。

    或许你很好奇我的说法,不应该直接断定是DHCP获取地址失败吗?

    其实不止,如果是使用静态ip地址,而ip冲突了,那么该设备就会处于没有ip可用的状态。

    它会启用与DHCP获取ip失败时一样的补救措施,使用169.254.X.X。

  • 假设是DHCP自动获取ip,那么我们会看到ip地址租期以及DHCP服务器的ip地址。记录服务器地址

查看网络信息要做的测试

第一步就是测试到网关的连通性。

请注意,不要只相信Ping的结果,很多时候会遇到禁Ping的设备,遇到拦截Ping包的防火墙。Ping的通的好说,Ping不通时,我们还要使用telnet、TCPing再测试一遍。

假设能通网关,说明从设备到机房设备这中间一段有没有故障。包括本地这边设备,设备到机房的链路,机房内的链路,机房网关设备。

这种情况下就再测试到达DNS的连通性,同时测试一下到达其他DNS的连通性(比如114.114.114.114;如果是纯内网环境,就ping内网里的服务器或者其他网段的电脑,以ip地址的方式)。

  • 若能通DNS,那么大概率故障不在下三层,而在上层。例如防火墙/策略/代理/对端服务未启用等等。
  • 若不通DNS(不止一个),那么大概率是网关到DNS的这段有问题。

假设不能通网关,那么就要先排查设备到机房的这一段了,包括本地设备的设置、硬件、网线、交换机等等。

可以进行的简单测试有拔插网线,检查水晶头,测线序,更换本地IP地址,更换本地mac地址(这两项更换测试完,记得改回去)

检查附近非故障机的网络信息

在非故障机上去验证能否联网,并查看以上的网络信息。

然后比对故障机与非故障机有什么配置区别,以排除ip/子网/网关配置错误的可能性。

如果是自动获取的,那么得看看网关是不是同一个设备,以排除是局域网内有私接的网关/路由器。

可以使用ARP命令查看网关的mac地址,mac地址不止可以确定是不是同一台设备;

mac地址的前6位代表网卡的生产厂商,我们可以借助厂商品牌大概推断会是什么设备。(比如是苹果的,可能是电脑;电信的,可能是路由器;TP-Link的,也可能是路由器)这也方便我们去找设备,重点找指定品牌的设备。

通过拔掉故障机的网线,在非故障机处ping/tcping故障机的IP,以排除IP冲突的可能性(通就说明冲突了,可以在通过ARP命令检查MAC进一步确定)

假设故障范围大

以网络完全不通为前提。

通过询问与寻线,找到故障机们最近的上一级交换机,将该设备重启,并检查主线水晶头与线序(最好是用寻线仪检测)

假设线序不正确或者主线不亮,证明链路有故障。

重打链路两端的水晶头后再次检测。(对端就靠寻线过去)

寻不到线或者故障依旧则可以放弃该段链路了(后者如果是测线序有大于4芯亮的,那还可以抢救一下,打1236走百兆)

值得注意的是,找到设备的时候一定要摸一摸,并观察指示灯,以排除设备过热/硬件故障等可能性。

断开交换机上的主线,保持其他不变,检查故障机彼此是否互通。

若互通,说明该交换本身以及到设备都是没问题的。

若不通

  • 检查水晶头,检查是否环路
  • 更换交换机测试

有条件在这里测试主线直连故障机是否能正常访问网络。(推荐常备网络直通头,直接使用直通头连接主线与故障机的网线。)

没有条件的,用主线直连自己带的笔记本,测试能否通网关。

如果直连网络可通,那么尝试更换该交换机上主线的接口。

  • 假设更换接口都不可使用,检查其余网线上的水晶头是否正常,线长有余裕的就直接重打水晶头
  • 假设故障依旧就更换一台交换机

如果直连网络都不通

  • 第一步还是检查水晶头,有条件重打主线的水晶头
  • 水晶头无误,则再寻线去到更上一层交换机处进行以上检查

假设故障范围小

也就是故障限定在一台设备,请先排除IP冲突,以下是排除IP冲突后的处理过程。

第一步依旧是检查到网关的连通性。

  • 若不通再检查到同网段其他电脑的连通性(比如隔壁电脑)
    • 若通其他电脑,说明可能是有策略或者防火墙将本地电脑拦截。
    • 若依旧不通,ping 127.0.0.1测试是否设备网卡或协议存在故障。
    • 若通本地127.0.0.1,则检查物理链路(水晶头、网线)
    • 若不通127.0.0.1,则说明设备网卡有故障
  • 修改ip地址再进行一轮测试,以排除IP冲突或IP被禁用的可能性
  • 修改MAC地址再进行一轮测试,以排除MAC被禁用的可能性
  • 进入带网络功能的PE系统,以排除系统问题
  • 将非故障机的网线接入故障机,以排除线路问题(包括交换机端口问题以及端口设置问题)
  • 将非故障机的网线接入故障机,依旧不通网,就同时将故障机的IP与MAC都修改为该非故障机的,再测试
    • 若这时通了,说明是上层配置问题(策略/防火墙等)
    • 若不通,找个usb网卡再接网线测试

有时,我们会接触到带认证客户端的设备,需要认证通过才能联网。

  • 这种就需要看情况处理,一般来说,先检查IP与MAC地址是否与其他设备冲突
  • 接着排查账号问题(在故障机使用其他账号登录,以及在其他设备使用刚刚故障机上的账号)
  • 若确定账号没问题,故障依旧存在则检查整体链路是否有问题。将非故障机的网线接入故障机,以排除线路问题(包括交换机端口问题以及端口设置问题)
    • 若此时通网了,说明是链路有问题(包括链路是否能通认证服务器)
    • 若不通网,则说明链路无故障,故障出现在与设备相关的地方。
    • 重装认证客户端测试
    • 若还是不通网,则将IP地址与mac地址设置为非故障机的,再此测试以排除IP或MAC被拉黑的可能性。
  • 另外,也可以同时去认证服务器端,查看日志。

假设故障为部分应用上不了网

一般这种情况就是链路并无故障,主要是上层故障导致的。

  • 我们可以先直接ping ip地址,再次确定是否下三层通的。

  • 接着更换DNS以排除DNS解析有误导致的。

  • 更换DNS后,可以手动清除DNS缓存,并使用nslookup命令检查DNS解析状况。(必要的话,检查本地hosts文件)

  • 接着检查设备是否开启了代理。

  • 关闭本地防火墙尝试一下。

  • 若是浏览器打不开网站的这种情况,那么就在浏览器设置里清空缓存与cookie,重启浏览器。

    1. 若依旧不行,再检查浏览器的权限设置,插件管理。
    2. 依旧不行的,更换浏览器再测试一遍。
    3. 同时可以去其他电脑访问该网站以排除对端服务器的故障/网关策略问题。

疑难杂症与”玄学“

通又不完全通(延迟、丢包)

这种情况,多半都是物理层面的故障导致的(设备故障、链路损伤、信号干扰等)。

  • 其中设备故障并不一定是设备坏了,也可能是过热、过载、甚至电压不稳定的原因。(不一定是交换机/路由器,终端设备(电脑/摄像头)也会如此)
  • 链路损伤包含了线路破皮、潮湿、弯折角度过大(光纤更敏感)。
  • 信号干扰一般来说就是电磁信号干扰,导致网线内部传输的电信号发生变化(磁生电)。

由原理推故障都好说,但现实实操的时候,遇到故障很多时候都会犯迷糊。

因为现实生活中,变数很多,很多时候人为的因素会导致我们无法一时间发现问题所在。

举一种常见的情况——接到报障,赶到现场,故障却已消失。

也有的时候是故障只持续数秒,十数秒,根本来不及检查。

这种情况只能花时间慢慢去验证,包括观察周期、规律,摸清设备的网络走向(布线走向与交换机位置)

我提几个存在过的实际案例(部分不是我个人经历)

因后期办公室增加了设备等原因,办公室内新增了交换机以满足使用需求,交换机也因此只能放在办公室桌子上或随意找地方放置,电源插头也接着办公室插排上。

  • 在此情景下,因为交换机被放在窗台边缘,当气温高且晴天时,太阳长时间直射交换机,导致设备过热。
  • 在此情景下,因为交换机占用了插排的一个接口,如果有员工短时间需要接入其他电器,有可能会直接拔了交换机的电源。
  • 在此情景下,因为交换机被放在热水壶等大功率电器附近,或者当电源接在同一插排上,当电器启动,短时的磁场变化或短时的电压变化冲击都可能导致网络波动。
  • 在此情景下,因为交换机被放在热水壶边,烧水壶长期的热量导致设备过热。(尤其是有的员工习惯使用养生壶保持高温烧凉茶/果茶)
  • 在此情景下,交换机到新增设备的网线都是采用明线的方式布置,有的是在地毯下,有的是在地面线槽下,有的是穿过桌子。
    • 在这种情况下,可能因为线路长期踩踏/桌子等重物压迫,线皮可能破损。破损后,如果在被踩踏/牵扯,可能会导致破皮的两芯接触导致信号错乱。
    • 在这种情况下,可能因为水晶头制作不良/老化/接口松,网线被牵扯导致接触不良,引起“网络波动”。

小结

其实吧,没必要分这么多情况。我个人认为,只要你了解了网络通信的原理,那么什么会导致网络通信失败都是可以推出来的。

比如说网络通信需要设备进行报文的处理,这设备的本质不就是个CPU嘛,那么反过来我问问你,什么情况会让你CPU运行状态不好?(供电/降频——电压不足不稳、过热、过载)

再到计算机网络,MAC地址、IP地址、网段、DNS、DHCP、路由、防火墙等等他们的原理,他们的用途,都是可以推出故障点的。

回到本文,其实我对本文的结构并不满意,不够由浅入深,循序渐进;确实不好写,故障因素太多了,很难分类。

只能希望读者能全文仔细看完,进行学习内化,本文并不适合作为在现场翻看的指导书。